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PREFACE 


The views expressed here are based on nearly 30 years experience modeling the structure of 
various kinds of organizations—both large corporations and government agencies. This 
modeling has never been technologically oriented. While the models are often the basis for 
very effective database designs, that is not their original target. 


Instead, these have been models of the "essential" aspects of an enterprise. What is the 
enterprise trying to do, and what are the intellectual structures required to do it? Among 
other things, this approach is extremely powerful as a way of engaging business people in 
deep discussions about the nature of their business—whether it be a corporation or a 
government agency. 


These early experiences brought about the discovery that there are common ways to describe 
common business situations, and that discovery was the basis for the book, Data Mode/ 
Patterns: Conventions of Thought. 


The book was published in 1996, shortly after Erich Gamma and his colleagues published 
Design Patterns: Elements of Reusable Object-Oriented Software’. Where that book described similar 
ways to code common problems in software, however, the Data Model Patterns book was 
concerned with similar ways to describe the nature of an enterprise itself. These books each 
broke new ground in their respective areas. 


From 2006 through 2007, the author of this article participated in the Federal Office of 
Management and Budget’s “Data Architecture Sub-committee”. This sub-committee was 
charged with providing guidance on data issues for agencies across the Federal 
Government. At this time, the committee had already recognized the distinction between 
Data Definition (What do the data mean’), Data Communication (What messages go 
from one place to another?), and Data Context (How ate the data used?) . 


This seemed a reasonable way to organize the issues. From there it was expected that the 
group would address at least the issues of Data Definition and Data Communications. 
Modelers ate very interested in the former, the hope was to contribute to the conversations 
concerning Data Definition. 


ORIGINS OF NIEM 


Because of the attacks in September, 2001, communication between government bodies 
took on a new priority. In response, the Department of Justice worked with 20 states to 
address the challenges of exchanging information across state and city government 
boundaries. The result was the Global Justice XML Data Model, released in its initial form 
in 2003. At the same time, the Department of Homeland Security was also looking to 
standardize their approach to standardize their data communications. 


1 David C. Hay.1996, Data Model Patterns: Conventions of Thought. (New York: Dorset House). 


2 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. 1995. Design Patterns: Elements of 
Reusable Object-Oriented Software. (Reading, MA:Addison Wesley). 
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The two agencies joined forces and in 2005, launched the “National Information Exchange 
Model’. In 2010, they were joined by the Deparment of Health and Human Services. 


According to the webside, NIEM.gov, “NIEM connects communities of people who share a 
common need to exchange information in order to advance their mission.” 


ABOUT MODELING AND XML 


The model was developed using XML, a data interchange language which was originally 
developed to support data communications. There were no graphic components. Thus, 
while it did indeed address Data Communications (XML’s forté), it was singularly unsuited to 
describing the stucture, rules, and meaning of data in a way that could readily be discussed by 
non-technical agency personnel. It did not address Data Definition. 


As it happened, enthusiasm for NIEM motivated the Data Architecture sub-committee to 


pay much more attention to Data Communications than it did to Data Definition—even as it 
became clear that communication cannot take place without first agreeing on the definitions. 


Unfortunately, since a technique suitable for describing the semantics of data structure (with 
its associated disciplines) was vot used, the result was not adequate to serve as a basis for 
Government-wide (or any inter-government) communications. If the semantics on the 
receiving end are not identical to the semantics on the sending end, no communication can 
succeed—no matter how cleverly the communication is constructed. This is true even if the 
failure is not immediately noticed. 


The assignment then was not to concentrate on the technology of sending messages, but 
rather on the meaning of the underlying data in both locations. 


Over time, this deficiency came to be acknowledged. Indeed, on the web site, it is now 
asserted that “... words are to a dictionary as elements are to a data model. Think of the 
NIEM data model as a data dictionary of agreed-upon terms, definitions, relationships, and 
formats—independent of how information is stored in individual systems. The data model 
includes community-specific elements as well as core elements that are commonly agreed to 
by all of the communities who use NIEM.”” 


This suggests that a model-that is a graphic representation of something—may have been 
used to guide the creation of definitions in NIEM. There is, however, little evidence of this 
in any of the NIEM publications. 


In the years since these 2007 conversations, some agencies apparently did recognize the need 
for models, but NIEM included no graphic tools, so any models created had to be either 
outside NIEM, or in the text of XML. 


Some efforts apparently were made to bring together non-technical people to validate the 
models, but it is unclear how effectively that was done. An audience that simply nods its 
head in agreement with something that no one understands is not validation. 


> National Institutes of Health. “About NIEM”. Retrieved 9/14/2014 from 
https://www.niem.gov/aboutniem/Pages/niem.aspx. 


*  Thid. 


It is true that in the interviening years NIEM has come to be based on a “Core data model”, 
with the idea that particular agencies could then “attach” their own models to the Core. 
This Core, however, is simply an XML Schema. What a data modeler would call an “entity 
type” is represented in NIEM with text as a “<complex type>” and/or a “<simpletype>”’. 


Without a graphic representation, and without the other components of comprehensive and 
sementically complete data models, it is not clear that the NIEM model is coherent, and it is 
not easy to get a non-technical person to determine whether its assertions are true. 


A RESPONSE 


In 2011, your author published Exterprise Model Patterns: Describing the World. This is a more 
comprehensive successor to the original data model patterns book. This did not invalidate 
any of the patterns in the first book, but built on them and placed them in context. Among 
other things, this book attempted to address apparent Data Definition issues faced by the 
Federal Government—but of course the book's patterns apply generally to the commercial 
wotld as well. 


In a spirit of good citizenship--out of concern with how effectively tax dollars are spent-- 
your author spent a couple of months studying the NIEM models. To support this effort, 
he took the training available on “NIEM Advanced Technical Concepts”, and also studied 
the “National Information Exchange Model Naming and Design Rules”. He also did what 
he calls “data archeology’, studying in detail the XML Schema file that constitutes NIEM 
3.0. 


After working his way around the XML Schema definitions of the Core 3.0 model, he finally 


felt that he understood what was going on well enough to set out to model a sub-set of Core 
3.0. 


This document is the result of that analysis and modeling effort. It addresses specific flaws 
in the NIEM “model”, and presents graphic representations both of the model as it now 
exists, and of some suggested changes. 


5 David C. Hay. 2011. Enterprise Model Patterns: Describing the World. (Bradley Beach, 
NJ:Technics Publications). 


6 National Institutes of Health. “Online Training”. Retrived 9/13/2014 from 
https://www.niem.gov/training/Pages/online.aspx. 


7 — Croft, Daniel (Nih/Cit) [G], Institute For Intergovernmental (lit) Research For United States 
Department Of Justice (Doj). “National Information Exchange Model Naming and Design 
Rules”. Retrieved 9/13/2014 from: http://reference.niem.gov/niem/specification/naming-and- 
design-rules/1.3/niem-ndr-1.3.pdf. 
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PART ONE: MANAGEMENT SUMMARY 


INTRODUCTION 


This document is an evaluation of selected sections of the National Information Exchange 
Model’s (NIEM) “Core” (Version 3.0). This model is based on the XML Schema definitions 
originally chosen to support inter-agency communications. Since XML is a linguistic model 
and not a graphic one, for this evaluation, the selected sections had to be translated into a 
graphic notation that would allow evaluation of the semantics, rigor, and truth of the textual 
version. 


Note the use of “selected sections”. The core model in its entirety consists of over 200 
complex and simple “types”. This analysis takes 33 of these and addresses them in terms of 
four subject areas: 


e People and Organizations 
e Items and Associations 

e Activities 

e Documents 


This document describes some issues that arose out of that approach, and makes some 
suggestions for alternatives. 


Two APPROACHES 


Practitioners in the information technology industry have long suffered from a bias towards 
THE CURRENT TECHNOLOGY (whatever that means this month), without 
necessarily understanding the nature of the business that the technology was intended to 
serve. In those cases where a project begins by attempting to apply technology to a 
problem—without first understaning the nature of the business that has the 
problem—invariably this results in the development of systems that, at best, are unnecessarily 
complex, and, at worst, simply do not work at all. 


XML has become very popular as a good vehicle for describing the messages that constitute 
Data Communication, It is, however, a very poor technique for describing Data Defiition. 
That is, it is not appropriate for describing (and discussing with non-technical people) the 
underlying structure of an agency’s data. 


An alternative approach for NIEM would have been to begin by doing a model of the 
semantics behind a government agency. Patterns such as those in Enterprise Model Patterns: 
Designing the World provide a basis for defining such fundamental underlying structures. 
Every agency will be concerned with people and organizations, geography, physical assets, 
and activities. These can be modeled in a standard way, such that once they have been 
agreed to, individual agencies can then elaborate on them to meet specific needs. 


8 Op. cit., Hay, Enterprise Model Patterns. 
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At that point, when communicating agencies agree as to what terms mean, they can define the 
means for communicating between them. At this point, XML is a perfectly good means to 
do so. 


This document takes the XML Schema-based models that are now the “Core” of NIEM and 
show how they can be corrected and elaborated upon, using data modeling graphics and 
disciplines. 


SUMMARY 


This document is in response to the discovery of two things about the NIEM Core. 


The first discovery is that she technical architecture is very clever. The basic unit of the model is an 
XML Schema “ComplexType’,, which is usually in the role of what data modlers would call 
an “entity type”. That is, it represents the definition of something of interest. Each of these 
may be further defined by one or more XML Schema “Elements”, which are either what 
data modelers would call “attributes” or references to other elements or to other complex 


types. 


The clever bit in NIEM is that each ComplexType must have as an element at least one 
“AugmentationPoint”. This allows another ComplexType to declare itself an enhancement 
(with its own elements) to the original ComplexType. This is what allows each agency to 
build more specific models, making use of the underlying structure of the Core model. 


The second discovery is that the semantics of the “Core Model” are very poor. This is not due to a 
lack of diligence on the part of the developers. Rather, it is at least in part because the 
orientation towards XML rather than a more graphic modeling language made it very 
difficult to see and address semantic issues. The overall effort would have obtained great 
benefit had it begun with a proper generic “Enterprise Data Model’, and not a detailed 
XML model of the Justice Department. Buried in the details of ComplexTypes, Elements, 
and AugmentationPoints, it is difficult to see (and discuss with users) the underlying meaning of 
the model. 


By starting with the decision to use XML technology to implement communications 
systems, without first using a mote appropriate technique for modeling the structure of the 
agencies doing the communicating, the NIEM effort has been much more difficult than it 
should have been. 


This implementation has been going on for some seven years now, and apparently, some 
agencies have been successful. Any agency using the model has had to reconcile it with its 
own view of the structure of things, and it is likely that some agencies have brought data 
modeling into the picture. It would be interesting to see the details of their 
implementation. 


Even so, it seems that there are still some fundamental semantic issues to be resolved. 


This document is an evaluation of the model that underlies the NIEM 3.0. 
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PART Two: SOME BASIC ISSUES 


The “National Information Exchange Model Naming and Design Rules” lays out the 
approach that has been taken to NIEM. It is very good at describing the specific restrictions 
applied to XML Schema to create a distributed modeling environement. It did raise some 
specific issues, however: 


On page 33 it describes ISO 11179 as the basis for constructing names. 


wow 
> 


Names must consist of "Object class term", "qualifier term" etc. 


Unfortunately, no where in the Naming and Design Rules is there anyhing about creating 


definitions. 


NIEM would greatly benefit from some guidance in this area. Unfortunately, in our 
educational system, most people have never learned how to construct a formal definition. 


In fact, a good set of rules available for NIEM to follow comes from Aristotle. A properly 
defined definition of a term includes: 


e =A major category that provides a context for the term (genus). 


e Something which differentiates the thing this term describes from that category 
(differentia)'” 
In NIEM, however (for example), OrganizationType is defined as 


"A datatype for a body of people organized for a particular purpose." 


Actually, no. What is important here is vot that an OrganizationType is a datatype. 
Rather, an Organization is a kind of thing in the world. It is not a "a data type" for 
anything." Strip off "A datatype for" and you have a reasonable definition of Organization: 
"a body of people organized for a particular purpose." 


An Organization is a body of people. It is not a data type. 
Unfortunately, all definitions in NIEM are of the form "A datatype for..." 


This is one of the reasons that in the model presented below, “type” has been removed 
from the names of what, in that context, are all "entity types". 


In addition, by removing "a data type for" from the NIEM definitions, most of them are 
OK 


Some are still problematic, though, perhaps because the definers got distracted by the 
"datatype" part. For example: 


PassportCategoryCodeType-"...a kind of passport" 


> NIEM Technical Architecture Committee. 2008. National Information Exchange Model 
Naming and Design Rules. Retrieved 9/4/2014 from 
bitps:| [www.niem.gov/ documentsdb/ Pages / documents.aspx 


10 Aristotle, as described in “Aristotle’s Logic: 7. Definitions”’. Stanford Encyclopedia of Philosophy. 
(Retrieved 8/31/2014, from bitp:/ /plato.standford.edu/ entries/ aristotle-logic.) 
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Actually, ¢hat is a defiition of Passport Category, not PassportCategory Code. The 
etror here is that the complexType was named incorrectly. The “code” should be an 
xs:element of PassportCategory(Type). 


DeviceType-"...a device" 


In philosophy, this is called a "tautology"—needless repetition of a word. This should not 
be allowed in definitions. Do not use a word to define itself. 


Organization -"a body of people organized for a particular purpose", 


Again, this is a tautology. Better would be "...a body of people brought 
together for a particular purpose") 


PetrsonConveyanceAssociationType-"...an association between a person 
and a conveyance." 


Unfortunately, this tautology follows a pattern used for every association definition in 
NIEM. The problem with this is that there is no information about the nature of the 


association. Is it "ownership", "rental", "use", etc.? 


PART THREE: ABOUT DATA MODELING 


KINDS OF DATA MODELS 


First of all, it should be understood that “data modeling” actually it not one technique but a 
suite of techniques. Over the years, the term has come to mean several different things. 
The first issue is that some people model data to support the design of data bases. Others 
model data to capture the underlying nature of an enterprise, be it a company or a 
government agency. Still others model the structure of a particular data management 


technology—such as a relational database, or a data communication specification in XML. 


Specifically, the following five categories of “data models” exist: 


¢ Corporate overview model — the view of a chief executive, capturing no more than 
a dozen or so key concepts. 


e Semantic model -— the view of the people who carry out the business of the 
organization. Because of different points of view, terms may be inconsistently 
defined, but the assignment is to capture the jargon of the business and bring it 
together as coherently as possible. Because people tend to view their worlds in 
concrete terms, the models colletivelly can be diverse and complex. 


e = ©Essential model —an integration of the collection of semantic models into a more 
abstract, simpler, more comprehensive model. This is in terms of the fundamental 
things of significance and assertions that define relationships between them. 


Note that all three of these kinds of models are independent of any technology that might be 
used to implement systems based on them. For that reason, various authors have described 
each kind as a “conceptual” model. 


¢ The design model (often referred to as the “Logical” model.) This an organization 
of the data according to a particular data management approach. This could be 
relational tables, UML classes—or XML “complex types”. 


e The physical model — this describes the way bits are actually organized on a 
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computer. This could be in terms of “tablespaces”, “partitions”, etc. 


XML — A “LOGICAL” DATA MODEL 


XML is about messages. Each message is inherently hierarchical and can contain anything 
the sender might want to say. It is organized in terms of “tags” that describe pieces of 
information. The definition of the tags is specified in an XML Schema “schema”. That is, a 
particular schema defines a set of elements, in terms of “types” and “elements”. 


The NIEM Core 3.0 model is a collection of such type definitions. For each concept to be 
communicated, there exists a “ComplexType’’, and sometimes a “SimpleType”. A 
ComplexType can have <element> occurring multiple times. These correspond to 
attributes in an entity/relationship model. One of the <elements> may be a reference to a 
corresponding SimpleType, which can contain constraints such as an <enumeration> of 
legal values. 


B5Qus! 


An <element> may also be a <ref>erence to another ComplexType. Thus, while the syntax 
of XML is fundamentally hierarchical, network structures are possible. 


As it now exists, the NIEM Core 3.0 is a Logical Model with a specific technological 
orientation. 


THE ESSENTIAL DATA MODEL 


The Essential Data Model is completely independent of any technology that might 
implement it. It could be converted easily into a relational database design, or into an XML 
Schema. 


The purpose is to describe classes of things of significance to the organization, along with 
assertions about how they are related to each other. Properly done, it is a combination of 
graphic and linguistic techniques. A model is a graphic representation of English language 
sentences that make very specific assertions about the organization. 


The point is that the assertions made could be false. This means that the model is not 
complete until everyone agrees to the truth of the assertions. This cannot be done if the 
aesthetics of the model do not promote understanding of it by non-technical people. 


Several notations are available, which add varying degrees of complexity to the conversation. 


The notation that was developed with this purpose in mind was by Richard Barker and 
Harry Ellis in the early 1980s. It was orginally only supported by Oracle’s Designer product, 
but that company has given up supporting it. Since then, they have another data modeling 
tool, and Informatica and Sybase have tools also that support the Ellis/Barker notation. 


In 2011, it became clear that by constraining UML, that notation can be used to good effect 
to accomplish what Messrs. Barker and Ellis set out to do. Enterprise Model Patterns'' uses 
UML in this way, and he explained the rationale for this in a companion volume, UML and 
Data Modeling: A Reconciliation". 


In this article, the NIEM models will be rendered in this modified version of the UML 
notation. 


About Names 


An essential data model describes classes of things of significance to an enterprise, about 
which it wishes to hold information. Each of these classes is called an “Entity Type”, An 
instance is called an “entity”. Thus, “Charles Davis” is an entity, while Person is an entity 


pe. 


Each relationship between two entity types encodes two sentences—one reading in each 
direction. There is a very specific syntax which imposes discipline on the modeler, but 
which, if successful, in each case produces a straight-forward sentence that is clearly either 
true or false. 
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Op. cit., Hay, Enterprise Model Patterns. 


12. David C. Hay. 2011. UML and Data Modeling: A Reconciliation. Bradley Beach, NJ: Technics 
Publications. 


p= 


Figure 1 shows how each sentence is composed of a subject, predicate, and object, with 
qualifiers that assert whether the relationship is mandatory or not, and how may of the 
object instances may be involved. 


Note that, in the example, if you started by simply saying “each Book must be about one and 
only one Topic, you would be wrong. Each book might cover many topics. One solution 
would be to change the cardinality, to add a “crow’s foot” to the line next to topic, but 
instead the modeler chose to simply constrain the relationship name to “primarily about” 


Language is important. 


Each 
<entity class 1> 
must be 


(or) For example... 
may be 


primarily 


primarily about <role name> Book | Topic 


of 1..1 


Pai | one and only one 


(or) 
one or more Each Book must be primarily 
about one and only one Topic. 


<entity class 2> Each Topic may be of one or 
more Books. 


Figure 1: How to Read a Data Model 


APPROACH TO DRAWING MODELS 


An important issue in producing a model to be read by the general public is aesthetics. 
Clearly in XML, there is no aesthetic component. In data modeling, however, it is possible 
to create drawings that, while they may be true, are completely unreadable. 


For this reason, the models you see here will have several constraints: 


1. While in some cases, there are as many as 15 boxes on a page, at no time are there 
more than 6 highlighted. Those are the ones that are different in a diagram slide 
from the diagram slide which preceded it, so they are the ones the viewer can focus 
on. 


2. All relationship lines are straight. There are no elbows. You can tell directly which 
two entity types are connected. 


3. With two exceptions, the entity types are organized so that the “many” side of 
relationship is always to the left and up. The exceptions are: 


Ss {= 


e Inthe cases where the assertion here is that the cardinality is in error. 


e §6External super-types, Object and Association. These super-types should be 
outside the boxes that are sub-types, but because they are so pervasive, they are 
on either side of the diagram. 


The point is that the diagram is expected to be comprehensive, complete, and true. This is 
not something you can assert with confidence about models rendered in the text of an XML 
Schema. 
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PART FOUR: SAMPLE MODEL 


The model is shown below in 5 sections: 
e People and Organizations 
e Items and More Associations 
e Activities 
e Documents 
e The Complete (so far) Model 
In each case, there are two to three drawings: 
e The model as derived from the Core 3.0 XML Schema. 
¢ The model as corrected according to the issues raised. 
¢ The model enhanced by adding some patterns from your author’s experience. 


In each initial case, the drawings are dirctly derived from the text of the schema described 
for NIEM Version 3.0. At least that is the intention. Readers are welcome to contact 
dch@essentialstrategies.com if there are any errors. 


NIEM 3.0 goes far beyond the topics introduced here. For each one presented, however, it 
is possible to produce a clear graphic representation. The discipline of producing the 
drawing then fleshes out logical problems that are not clear when studying just the XML 
Schema code. 


SOME LIBERTIES WITH THE NIEM MODEL... 


First, a few words about drawing a model. A model should be drawn so it can be presented 
to non-technical audiences that may have had no experience with data modeling. The 
models may get complex, but the complexity should be limited to that of the content of the 
model. The style of presentation should not add to that complexity. 


For this reason, the models shown here are constructed piecemeal, so that for any one 
drawing, only a few "entity types" are highlighted. 


Also, while it does purport to represent NIEM accurately, in the interest of clarity, the 
following liberties have been taken: 


e Since all of the ComplexTypes are named "../Type", and since, by definition, my 
diagrams represent "entity types", it seemed unnecessary to include that word with 
each name. That distracted from its underlying meaning. 


e Since the purpose of the drawing is to present the model to English-speaking 
readers, spaces have been inserted between the words in entity type names. Among 
other things, this practice allows the names to be "wrapped" coherently. 


e The major super-types in NIEM are Object and Association. Because so many 
entity types are extensions of these two, they are represented in the standard UML 
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fashion—that is, separately, with connecting Lines. In other cases, however, in the 
interest of readability, sub-type boxes are shown zuside the super-type boxes. This is 
intended to produce a more compact and more readable model. 


In each section, you have first, a model constructed exactly from the XML Schema 
statements. Because XML does not have the concept of naming relationships, initially, there 
are no relationship names. The second version makes the corrections required, and adds 
some names for clarity. In the third form, the model is enhanced, making use of patterns 
and good modeling practices. This includes, among other things, adding all relationship 
names to all. 


PEOPLE AND ORGANIZATIONS -- NIEM VERSION 


Figure 2 shows the entity type boxes that represent Person, Organization, Organization 
Unit, and Entity, plus some immediately related entity types. Several things become 
immediately apparent: 


Person and Organization 


In my experience, nearly every model for every industry has included entity types for Person 
and Organization. NIEM is of course no different. In the world of essential data modeling, 
however, it is also common to declare a super-type for these two entity types. It has long 
been industry practice to name that "Party", but other names have been applied as well. 


In the NIEM model, on the other hand, these two entity types (complexTypes) are shown as 
sub-types (extensions) of structures:objectType. There is nothing wrong with that, 
except that nearly everything is a sub-type (extension) of Object. As shown in Figure 3, this 
includes Activity. There is not much information conveyed by this, especially since there is 
no definition of structures:objectType in NIEM 3.0. 


Person Association 


If PersonAssociation is "...an association between people", the model should show that 
the entity type has at least two relationships, one to each Person in the association. In the 
current model, however, the complexType "PersonAssociationType", has onlyone 
element description: 


<xs:element ref="nc.Person" 
minOccurs="0" 
maxOcurrs="unbounded"/> 


In Figure 2, this is shown by "0..*" on the relationship line from Person Association to Person. 


What this says is that the association may be with one or more people. That is, you could have 
an association that is with no people or only one person. This is (dare it be said?) nonsense. 
It is defined to be "an association Letween people". Note that in English, the word "between" 
implies exactly two. Here, this one association could be with more than two people. If it is 
between two or more people, what is the role played by each? Again, if, for example, the 
Person Association is between mother and daughter, who is the mother and who is the 
daughter? 
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To be coherent, a three-way association among grandmother, mother, and daughter should 
be represented as two binary relationships. This way Sally can be "daughter" to Edith, but 
"mother" to June. Moreover, it is reasonable to assert that in no case is one person related 
to h'self. 


Bison ~~ Person Disunion? 


Person Union 
Association 


Association between two 
Persons / Organizations. (??) 
T 


Organization 
Unit? 


Figure 2: People and Organizations - NIEM 


Corrections 


To summarize, Person Association needs #0 relationships: one referring to one Person 
(the "from" relationship); and a second one referring to a different Person (the "to" 
relationship). Moreover, each of the relationships must be to exactly one Person. The 
model should be changed to reflect that. 


In the schema, this would call for two xs:elements. 


== fh 


<xs:element ref="nc.FromPerson" 
minOccurs="1" 
maxOcurrs="1"/> 


<xs:element ref="nc.ToPerson" 
mindccurs="1" 
naxOcurrs={" 1" /> 


For example, one could be to "Mother" and one could be to "Daughter". 


This is shown in the “corrected model’, as Figure 3. 
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Figure 3: People and Organizations — Corrected 


As previously mentioned, the relationship names follow a very specific structure, as 
described in Figure 1, above. (See page 11.) Specifically, in Figure 3, each Person 
Association must be fro one and only one Person, and each Person Association must be 
to one and only one Person. 


Going in the other direction, each Person may be on one side of one or more Person 
Associations, each of which must be /# one and only one (other) Person. That is, each 
Person may be related / one or more other Persons, and each Person may be related from 
one or more other Persons. 


Note that his is the standard pattern for representing any many-to-many relationship 
between instances of the same entity type. 
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Organization association 


The problem with the relationships between Person Association and Person also applies 
to the recursion of Organization as well. As with PersonAssociationType, in the NIEM 
model in Figure 2, there is only one "link" between OrganizationAssociationType and 
Organization: 


<xs:element ref="nc.Organization" 
minOccurs="0" 
maxOcurrs="unbounded"/> 


Can you have an Organization Association ("an association between 
organizations") that is not about any organizations? About one organization only? If it 
is between two Organizations, and is, for example, about corporate structure, how do you 
know which organization is the company and which is the department? 


In the schema, this would call for two xs:elements. 


<xs:element ref="nc.FromOrganization" 
minOccurs="1" 
maxOcurrs="1"/> 


<xs:element ref="nc.ToOrganization" 
minOccurs="1" 
maxOcurrs="1"/ 


As with the Person Organization relationship, this too is updated in Figure 3. 


Entity(Type)? 


According to NIEM, an Entity (Type) is "a person, organization, or thing 
capable of bearing legal rights and responsibilities". Like Person and 
Organization it is a sub-type of Object. It is neither a sub-type nor a super-type of either 
Person or Organization. 


First of all, "things" are not capable of bearing legal rights and responsibilities. 


If a Person playing this role could be characterised as a "sole proprietership" (a "virtual" 
organization), then this cou/d be a sub-type of Organization. 


Thus, it is reasonable to postulate Legal Entity as a kind of Organization. This is an 
Organization (in the U.S. a Corporation, Partnership, or Sole Proprietorship) that has a 
legal status and is thus able to carry out contracts. This is also updated in Figure 3. 


(Organization) Unit? 


Organization Unit Association is defined as “an association between an 
organization and another organization or unit”. The only problem is that 
there is no Unit. What is that? Are we missing a complex type? Is it a sub-type 
("extension") of Organization? 


For that matter, in NIEM, there appear to be no sub-types of Organization. Both (Legal) 
Entity and Unit are shown as sub-types of Organization in Figure 3. Note that with Unit 
as a sub-type of Organization, the entity type Organization Type Association is no 
longer necessary. It is subsumed into Organization Association. 
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What is a Person Disunion? 


A Person Disunion is defined as" a legal termination of a Person Union". 

One could assume that this has something to do with a PersonUnionAssociation. But 
there's no way of telling which one. There is no link in the NIEM Core 3.0. It seems likely 
that if two people have a divorce, they must have started with a marriage. 


The relationship showing that each Person Disunion must be Lased on one and only one 
Person Union Association, and each Person Union Association may be /0 break up one 
and only one Person Union Disunion has been added to the drawing that is Figure 3. 


(Actually, a Person Union Association would be better named simply Person Union, but 
that will be taken up in the next section, below.) 


PEOPLE AND ORGANIZATIONS — AN ALTERNATIVE 


Figure 4 shows an alternative for the Person/Organization model, which introduces two 
new sub-types for Organization, plus a new entity type — Party. 


Most basic kind of super-type for Person and Organization, is called—by 
convention—Party”. That is,"a person or organization that is of 
interest to the company or agency being modeled.” ‘Thus you 
may have two (or mote) "parties" to a contract, one of which could be a Person or an 
Organization and the other also could be a Person or an Organization. 


Thus, in the Figure, the entity type Party is shown as a generalization of Person and 
Organization. 


Also shown are four sub-types of Organization. Two are from the previous diagram. 
(Legal) Entity we discussed. In the NIEM Core Model documentation, Unit was not 
defined but hypothesized. 


The book, Enterprise Model Patterns:Describing the World*, shows that an Organization may be 
a Company (e.g, "Legal Entity", such as a “Corporation”, “Partnership”, or “Sole 
Proprietorship), Department (for some clients, this is called "Internal Organization", but it 
could also be NIEM's "Unit"), Government (the organization that has overall jurisdiction 
for a Geopolitical Area—another discussion—or Government Agency (a component of a 
Govenment that is responsible for a particular regulatory—or military—function). It also 
could be something that is none of these, like a union or a political party. This structure has 
wotked well for many large corporations, as well as several government agencies—both in the 
United States and Canada. 


Also in Figure 4 is the renaming of Person Union Association to, simply, Person Union. 
It is much mote reasonable that a divorce is coming to a Person Union than to an 
...Association. 


15 Op. cit., David C. Hay, Data Model Patterns: Conventions of Thought.. 
14 Op. cit., Hay, Enterprise Model Patterns: Describing the World.. 
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Figure 4: People and Organizations — an Alternative 


Figure 5 shows a more compact version of Figure 4, with Person and Organization shown 
inside the new super-type Party. 
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Figure 5: People and Organizations - Compact 


ITEMS AND ASSOCIATIONS — NIEM VERSION 


Figure 6 adds the concept of Item, "an article or thing". The only sub-type 
contained in NIEM 3.0 is Conveyance, which in turn contains the sub-types Vehicle, 
Vessel, and Aircraft. This definition of Item of course provides a great opportunity for 
vatious agencies to add a massive list of additional kinds of Item. 


This drawing also introduces an entity type called here Association, known in NIEM as 
AssociationType. Note that, while most things are sub-types of Object, most 
associations are sub-types of Association. 


Figure 6 also introduces the concept of Item Entity Association, linking Item and Entity. 
Its definition, alas, is not very informative: "an association between an item 
and an entity." As described previously, a tautology is not very useful as a definition. 
There is, however, a more serious logical problem with this and the other associations. 


In this case, there ate two relationships describing the links to Entity and Item: This is 
represented in Figure 6 by “0..*” on the lines next to Entity and Item, respectively. 


In the Core schema, these relationships are represented as xs.elements of 
ItemEntityAssociationType: 


<xs:element ref="nc:Entity" 
minOccurs="0" 
maxOccurs="unbounded"/> 
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<xs:element ref="nc:Item" 

minOccurs="0" 

maxOccurs="unbounded"/> 

What this is asserting is that a single instance of Item Entity Association can associate one or more 
instances of Entity with one or more instances of Item. This makes no sense. This makes it impossible to 
address a particular instance of one with the other. 


Person Association Person 
0..* from - 
on one fat Object 
How is Association side of 
Type (Type) identified? 0..* ‘ 
— ao _| yl 
on the 1.1 
other 
side of 
Cardinality: One Item 
Entity Association must 
be between ONE Item 7 
and ONE Entity ae - 
H Organization from Organization 
nN | Association | onone 1.1 
\ | side of 
i 
0..* to =r 
' on the 1.4 
! other 
i side of 
1 
; 
0.) Entity | —___— = 
——o | 
_Item Value | 
7 NS 
No Connection between 
Item Value and Item 
Intangible Item 
——D 


Figure 6: Items and Associations - NIEM 


What is probably meant is that each Item is associated with one or more Entities and vice versa. But the 
way to say that is to assert that each Item may be associated with one or more instances of Item 
Entity Associations, each of which must, in turn, then be associated with exactly one 
Entity. Similarly, you can assert that each Entity may be associated with one or more Item 
Entity Associations, each of which must, in turn, then be associated with exactly one Item. 


To generalize this problem, each instance of any associative entity type must always link 
exactly ove instance of thing A with exactly one instance of thing B. In the case of our 
example, you should have: 


e <xs:element ref="nc:ItemType" 
minOcecurs="1" 
maxOccurs="1"/> 


e <xs:element ref="nc:EntityType" 
minOcccurs="1" 
maxOccurs="1"/> 


Thus, in Figure 6, at the end of each relationship to the thing being related, where it now 
shows "0..*", it should show "1". 


Note that NIEM has no information as to the relationship from (for example) Item 7“ 
ItemEntityAssociationType. Similarly there is no information about the relationship from 
EntityType /o ItemEntityAssociationType. 


This turns out to be where the "0..*" labels belong. To be sure, from the point of view of 
the Item, there could be, optionally, more than one Item Entity Associations, since an 
Item may indeed be linked to one or more Entities. Similarly, one Entity may or may not 
be linked to one or more Item Entity Associations, since it may in turn be linked to more 
than one Item. 


In ItemType, then, you could have: 


e <xs:element ref="nc:ItemEntityAssociationType 
minOecceurs="0" 
maxOccurs="unbounded"/> 


Similarly, in EntityType, you could have: 


e <xs:element ref="nc:ItemEntityAssociationType" 
minOcccurs="0" 
maxOccurs="unbounded"/> 


I do understand that in sending messages (XMS’s domain), it isn't necessary to describe the 
relationships in both directions, but you should at least get the ones that you are describing 
correct. 


Issue: Item Value 


Figure 6 also shows a lonely entity type Item Value, which is defined as “an evaluation 
of the monetary worth of an item’. The only problem is that there is no reference to 
the Item that an instance of Item Value might be the value of. Also, the concept of value 
could apply to other diminsions besides money. To be correct to the definition, it should be 
called something like Item Financial Value. Better, however, would be to extend the 
definition to something like “an evaluation of a characteristic of an Item. This 
is addressed more completely, below. 
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Corrections 


Figure 7 shows the Items and Associations model with the cardinalities corrected, and with 
an enhancement of Item Value. 


As with Person and Organization, the first round of corrections is to move the cardinality to 
the correct ends of the relationships. Specifically, each Item Entity Association must be of 
one Entity and 7th one Item. Thus, each Entity may be on one side of one or more Item 
Entity Associations, each of which must be wth exactly one Item. That is, each Entity is 
optionally associated with one or more Items. Going the other direction, each Item may be 
on the other side of one or more Item Entity Associations, each of which must be of exaclty 
one Entity. Thus you have each Item optionally associated with one or more Entities, and 
vice versa. 


Second, Item Value in Figure 6 has no information as to either what it is a value of, or 
what it applies to. Figure 7 fixes this by explicitly introducing Item Characteristic, a 
reference entity type for describing all of the characteristics that could be used to describe an 
Item. 
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Figure 7: Items and Associations — Corrections 
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These could be anything from "height" and "width", to "RPM", "Horsepower", or "Disc 
size". It is then the task of Item Value to specify a value ofan Item Characteristic for an 
Item. That is, Attribue Characteristic is defined as"a number or string that 
may be used to quantify, qualify, or otherwise describe an 
Item." Value is nowdefinedas "the fact that a particular Item 
has a "value" for a particular Item Characteristic." 
Attributes include "value" of course, plus "effective date" and "until date". 


ITEMS AND ASSOCIATIONS — AN ALTERNATIVE 


Figure 8 shows an alternative representation of the Item Entity Association. 


As mentioned in the previous section, all of the Association(type)s in NIEM 3.0 are 
defined with the same kind of tautologies. For example, Item Entity Association is 
defined as" an association between an item and an entity." This is nota 
definition. 


There is no sense of the meaning of the association. It is always true that if you link two 
things together, they are “associated”, but without more to the model than that, not much is 
being communicated. 


This can be addressed at two levels: first by giving the association a more meaningful name 
and definition, and second, by adding an entity type with a list of values for the particular 
kind of the association is involved. 


In this example, we begin by renaming Entity Item Association to Item Role. This is 
accompanied by making the entity type linked not to Entity, but to our new entity type 
Party, which subsumes Person and Organization. We can further clarify the concept by 
adopting a convention that, unless otherwise specified, all “roles” are played by Parties. 
That is, an Item Role is defined as “The fact that a particula Party (either a 
Person of an Organization) is associated with the creation, use, or sales 
of a particular Item”. This, finally clarifies that people and organizations are involved, 
and secondly clarifies, in general terms, the nature of that involvement. 


A second step is to add the concept of Item Role Category. This is defined as “a kind 
of Item Role, such as “manufacturer”, “consumer”, 
“distributor”, etc.” Here you have the opportunity to define—as data—the kinds 
of roles that may apply. Thus, this is now in the hands of data governors and not data 
modelers. 


In Figure 8, you have the assertions that each Item Role must be p/ayed by one and only one 
Party, and must be for one and only one Item. Moreover, each Item Role must be au 
example of exactly one Item Role Category. 


See discussions of Activity Role and Information Resource Role below on pages 31 and 
35, respectively. 
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Figure 8: Items and Associations — An Alternative 


ACTIVITIES — NIEM VERSION 


Figure 9 adds the concept of Activity:"a single or set of related 
actions, events, or process". This is a large concept that so far only 
encompasses Incident (“a single or set of related actions, events, or 
process”), Treatment (“treatment of a person for a mental or 


Object 


physical condition”), and ItemTransaction (“transfer of ownership 


of an item”) 
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Note that these are activities in three very different domains. It is reasonable to expect that 
different agencies subscribing to NIEM will have their own set of sub-types for Activity. 


Item Transaction 


The ItemTransaction entity type has some interesting characteristics. As just said, its 
definition is “transfer of ownership of an item”. This requires three relationships 
These are described in the schema with three elements as components of 
ItemTranslationType. The first links it to the Item itself: 


<xs:element ref="nc:Item" 
minOccurs="0" 
maxOccurs="unbounded"/> 


... where nec: Item referred to is defined as: 


<xs:element name="Item" 
type="nc:ItemType" 
nillable="true” /> 


An article or thing. 


That is, each Item Transaction has an optional association with one or more Items. Since 
apparently this represents a sale, that is reasonable. This is an Item being sold. An Item 
Transaction may be for more than one Item. Going the other direction, we don’t know 
how many Item Transactions will affect a particular Item, but it is reasonable to assume 
that it would be more than one as well. 


That is, there is a many-to-many relationship between Item Transaction and Item. The 
conventional way to deal with this is to define an intersect entity type between the two. In 
fact, there already is one: Activity Item Association is just such an entity type. And it 
already exists! It does relate any kind of Activity to an Item, but in doing so, it has also 
related an Item Transaction to an Item. 


Issue: Why does the direct relationship between Item Transaction and Item exist? 
The other two relationships from ItemTransactionType are to 


<xs:element ref="nc:ItemSeller" 
minOccurs="0" 
maxOccurs="unbounded"/> 


Where nc: ItemSeller is defined as: 


<xs:element name="ItemSeller" 
type="nc:EntityType" 
nillable="true”/> 


A party that sold a Property Item in a Property Transaction. 
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Figure 9: Activities - NIEM 


..and... 


<xs:element ref="nce:ItemBuyer" 
minOccurs="0" 
maxOccurs="unbounded"/> 


Where nc: ItemBuyer is defined as: 


<xs:element name="ItemBuyer" 
type="nc:EntityType" 
nillable="true”/> 


A party that bought a property item in a property transaction. 


In Figure 9, the two relationships to Entity are labeled “ItemBuyer” and “ItemSeller’”’, in 
order to distinguish between the buyer and the seller roles. The relationship to Item does 
not have to be labeled, since “Item” is the role being played. 


Note that ItemTransactionType also has one xs.element: 


<xs:element ref="nc:ItemPurchasePriceValue" 
minOccurs="0" 
maxOccurs="unbounded"/> 


This is shown as an attribute of Item Transaction on Figure 9. 


It is beyond the scope of this article to discuss attributes, but this does raise a flag. In the 
schema, Item Transaction is defined as “a transfer of ownership of an 
item”. This suggests that this transaction is part of a contract, but that is not included in 
this part of NIEM. In my experience, purchases have as attributes “Purchase Price” and 
"Quantity". Where possible, these two quantities are multiplied together to produce a 
derived attribute, “Value”. What, then is PurchasePriceValue? The attribute is not 
defined in NIEM 3.0. 


Recursive Relationships 


Note that the “entity type” Item Transaction has two relationships to the entity type 
Entity. These are labeled as to the roles being played. 


This is a common pattern in modeling. It first appeared in the 1970’s to describe “product 
structures”. You had a file (remember "files"?) describing all the parts, assemblies, and 
finished goods involved in manufacturing a product. (Yes, even then, it was called the 
“Item” file.) Another file contains all the links between raw materials, intermediates and 
finished products. Each “Product Structure” record would then relate one “Item” (the 
“component”’) to one other “Item” (the “assembly’’). 


This structure has perservered through five decades and is still used today to represent any 
network, where one instance of a “thing” can be related to one or more other instances of 
the same “thing”. 


In the case of Item Transaction Association, then, it should be defined as being 
concerned with the transfer of exactly one Item from exactly one Item Seller Entity to exactly 
one Item Buyer Entity. The “0..*” cardinalities shown on the drawing are simply wrong. 

This issue was discussed more thoroughly in addressing Item Entity Association, above. 
(See page 20.) 


Some people have difficulty connecting to this concept—and XML is not conducive to 
implementing it—but it is an incredibly powerful one. 


Activities — Corrections 


Based on the description above about intersect entity types, Figure 10 shows the corrections 
to adjust the cardinality of the entity types that link Activity to Person, Organization, 
Entity, Item and Conveyance. Notice that now we can see that each Entity may be a buyer 
in one ot more Item Transaction Associations, and each Entity may be a seller in one or 
more Item Transaction Associations. 


An additional correction removes the relationship from Item Transaction to Item. 
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Figure 10: Activities — Corrected 


ACTIVITIES — AN ALTERNATIVE 
Figure 11 shows an alternative to even the corrected model, above. 


More about buyers and sellers 


You'll note from the original model in Figure 9 that both the buyer and seller are 
Entity(Type)s. Remember that an Entity is defined as "a person, organization, or thing 
capable of bearing legal rights and responsibilities". Assuming that means what is 
conventionally refered to as "Legal Entity", are we constrained to buying and selling only 
from corporations, partnerships, or sole proprietorships? What about selling to a private 
person? Or-which is particularly significant to NIEM—a government agency? 
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Figure 11: Activities — Improved 


This is precisely why the data modeling world invented the concept of "Party"-- a super- 
type of Person and Organization. Organization, in turn, is a super-type of Legal Entity, 


Department (or Internal Organization), Government, and Government Agency-- 
among others. All of this was described in the section on “People and Organizations”, 


above. See page 18 for the alternative model in that category. 


The use of the Party allows one to have an Item Transaction between two Parties, where 


one is the buyer, and one is the se/ler. Either could be any kind of Party—Person or 
Organization. In fact, the Item Transaction usually has the more conventional name 


Contract (or "Agreement", depending on the company doing the modeling)"*. Since a 


contract is typically for more than one product or service, the relationship between it and 
Item has "0..*" on both ends. This was observed in the discussion of the original model, 
above. This makes data modelers uncomfortable, so they usually add Contract Line Item 
between the two, where ond Contract Line Item is part of one Contract, and for one Item. 
Conveniently in our model, we can make that a sub-type of Activity Item Association. 


15 


Op. cit., Hay, Enterprise Model Pattern:Describing the World, Chapter 15 "Contracts". 
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About Activity Item Association 


Figure 11 shows this inclusion of Contract Line Item as a sub-type of Activity Item 
Association. That is, each instance of Contract Line Item is also an instance of Activity 
Item Association. Specifically, Contract Line Item is the fact that a particular Item is 
being bought and sold under a particular Contract. That is, each Contract Line Item must 
be part of one and only one Contract, and must be for one and only one Item. This does 
mean, by the way, that the relationship Contract Line Item part of Contract is itself a sub- 
type of the relationship Activity Item Association from Activity. This is of no consequence 
to this discussion, but it is worth noticing, even so. 


Note also that Activity Convenence Association is also a sub-type of Activity Item 
Association. Each instance of the former is also an instance of the latter. 


Activity Roles 


Figure 11 also takes advantage of the Party entity type described previously. The entity 
types Activity Person Association and Activity Organization Association have been 
consolidated into Activity Role. This is defined as "the fact that a 
particular Party is somehow involved with the carrying out 
of a particular Activity". That is, each Activity Conveyance Association 
must be (like all instances of Item Activity Association) from one and only one Activity, 
and must be wth one and only one Conveyance. 
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DOCUMENTS — NIEM 
Figure 4 adds another topic: Document. In the NIEM 3.0 “documentation” (so to speak), 
itis defined as “a paper or electronic document”. 
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Figure 4: Documents 


This is wrong on two counts: First of all it is a tautology (a document is a document), 
addressed previously. (See page 8, above.) Second, instead of defining what it zs, it describes 


what its physical manifestation might be. 
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So far, the only Documents included are Passport and Manifest. To be sure, it can be 
expected that each agency will will have many more kinds than that. But are these two the 
most important categories that will apply to all agencies? One wonders. 


As with the previous models, the cardinality is wrong. Each ... Association, by definition, 
can only be of one thing 7th one other thing. The idea that (for example) an Activity 
Document Association can link one of more Activities with one or more Documents 
makes no sense. At the very least it cannot be implemented. 


What is probably intended is the assertion that each Activity may be associated with one or 
more Documents, and each Document may be associated with one or more Activities. 
But that’s not what’s being asserted. What the XML programmers probably didn’t realize 
was that the whole reason for creating the ... Association entity types in the first place is to 
implement this. 


As we saw in different contexts, this is done by saying that each Activity may be described in 
one ot more Activity Document Associations, each of which must be of one and only one 
Document. Going the other way, each Document may be operated on via one or more 
Activity Document Associations, each of which must be with one and only one Activity. 


In NIEM 3.0, you also have Image(Type) in the model. This is defined as “...a 
picture or visual representation of something.” Inthe NIEM 3.0 
schema, its extension is nc: BinaryType, of even nc:ObjectType. That is, there ate no 
semantic super-types defined. 


Figure 12 shows the corrections to the cardinality errors. 
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Figure 12: Documents — Corrected 
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DOCUMENTS — AN ALTERNATIVE 


Information Resources 


What this approach camouflages is the fact that "document", "image", "book", "e-mail 
communication", etc. all are in fact examples of a more general concept—which in Enterprise 
Model Patterns is labeled “information resource”. Figure 13 shows an alternative to the 
NIEM model that accounts for this more general concept. First, “information resource” 
itself is defined as “Any collection of concepts expressed in a form 
that can be communicated to others.” 
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Figure 13: Documents — An Alternative 


'° Op. cit., Hay. Enterprise Model Patterns: Describing the World. pages 256-257. 
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The Figure embodies this concept in two entity types: Information Resource Definition, 
whichis “Specification of the meaning and or content of an 
information resource”, and Information Resource Instance, that is “a 
physical or electronic embodiment of an Information 
Resource Definition”. 


The definition encompasses the sub-types Document (“an Information Resource that is 
text based”) and Image (“an Information Resource that is a visual representation of 
something’). 


Once you have Information Resource Definition, it is a reasonable step to assert that each 
Information Resource Definition may be embodied in one or more Information Resource 
Instances. Each of these must be either a Physical Copy or an Electronic Copy, and 
must in turn be stored in one and only one Medium. A Medium is “a means of 
effecting or conveying something: as .. a sustance regarded 
as the means of transmission of a fore or effet”. For example, it 
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could be a “Form’’, “Computer display”, “Newspaper”, etc. 


Note that the drawing asserts that each Information Resource may be embodied in one or 
mote Information Resource Instances, where each of these, in turn, must be stored in one 
and only one Medium. That is, a Manifest associated with a shipment may be embodied in 
three Physical Copies and one Electronic Copy. 


Information Resource Roles 


In Figure 13, there is another significant change to the original NIEM model: Activity 
Document Association has become Activity Information Resource Role, and Person 
Document Association has become Party Information Resource Role. The problem 
with “association” in an entity type name is that any connection between two entity types is 
an “associaton’”. There is no information conveyed by that name. 


“Role”, on the other hand suggests that one entity type is performing some action to create 
or manage the other. Note that in each case another entity type has been added to describe 
the nature of the role. 


That is, in addition to renaming the intersect entity types, another entity type (... Category) 
has been added in each case to allow for elaboration on the nature of that role. 


Specifically, Activity Information Resource Role is “the fact that a 
particular Activity is involved in the creation, use, or 
destruction of an Information Resource Instance”. That is, each 
Activity Information Resource Role must be p/ayed by one and only one Activity, must be 
Played for one and only one Information Resource Instance, and must be au example of one 
Information Resource Role Category 


For example, an Information Resource Role, dated “March 23, 2013”, could assert that 
the Item Transaction “Shipment of 2,000 cars from Korea to Long Beach” has the effect 


'’ Merriam Webster. 2010. “Medum”. The Merriam Webstr OnLine Dictionary. Retrieved 
11/16/2010 from http://ww.merriam-wester.com/dictionary/medium. 


(Activity Information Resource Category, “Issue Manifest”) of creating three Physical 
Copies and one Electronic Copy of the manifest with identifier “#345297-A”, 


There is a separate instance of Activity Information Resource Role for each Physical Copy 
and for each Electronic Copy created for an Item Transaction. 


Also in Figure 13 Party Information Resource Role is defined as “the fact that a particular 
Party (either a Person or an Organization) is involved in the creation, use, or destruction 
of either a particular Information Resource Instance or a particular Information 
Resource Definition”. Note that this encompasses not only Person Document 
Association from the NIEM model, but also an association neglected by NIEM-that of 
Organizations and Documents. 


In addition, note that the role could be either about the Definition of an Information 
Resoutce (the author), or one of the Instances (the sender). “Author” and “Sendor” are 
examples of Information Resource Role Category. 


Information Resource Topics 


Information Resource, by the way, is quite unlike any other subject area in modeling a 
business: 


No matter what the medium, it can be about anything else in the world. In the current version of 
he NIEM model, Document(Type) is associated with Person(Type) and Activity(Type), 
but it could be related to any other entity type (or attribute) in NIEM. 


If it were a library book, that industry has spent several centuries creating schemes for 
cataloguing it in terms of the world's knowledge. As a different example, for an intelligence 
agency to catalogue cables from overseas, and relate them correctly to people, organizations, 
events, etc. is not a trivial task. 


It is not for NIEM Cote to address those issues in detail, but it should provide the basic 
structure for doing so. A chapter in Enterprise Model Patterns..."* addresses this specifically. 


Note that, in the diagram, the dased line between the two relationships represents the 
constraint “exclusive-ot’’. Hence the sentence to read the two assertions cites that an 
instance of Party Information Resource Role must invoke one or the other 
relationships, but not both. 


18 Op. cit., Hay. Enterprise Model Patterns. Chapter 10, “Documents and other Information 
Resoutces. 


PART FIVE: THE COMPLETE MODEL 


THE NIEM VERSION 


Figure 14 is the complete view of the NIEM sections presented above. It is bad practice to 
present the last slide in models without going through the other ones first. If someone sees 


this first, they tune out—often even if they are modelers. Still, after seeing all the component 
models, some may find this interesting. 
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Figure 14: The Complete NIEM Model 
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THE COMPLETE CORRECTED MODEL 


Figure 14 shows the complete model with the corrections described above. Specifically, the 
following corrections have been made: 


1. Correcting the cardinality for intersect (connecting) entity types. 

2s Correcting the recursive models for Person Association and Organization 
Association. 

a The entities describing association roles could have been represented as ... Category 


entity types. Because they are implemented in a unique way in XML Schema, as 
"SimpleTypes", for the e/r model, it seemed more appropriate to show them as UML 
"enumerations". 


4, Organization Unit is recognized as a sub-type of Organization. 
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Person 


Figure 15: The Corrected Model 


THE IMPROVED MODEL 


Figure 4 shows a version of the model with all of the improvements described above. In 
addition to the corrections cited previously, the following additions and changes have been 
made to the original NIEM model. 
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(Note that in the “build-up” pictures, yellow shading is used to indicate the entity types that 
were new on each diagram. Here light blue is used simply to make the sub-types more 


visible.) 
i, 
a. 


Person and Organization have been made sub-types of the abstraction Party. 


Activity Organization Association and Activity Person Association have been 


made sub-types of Activity Role, the fact that any Party (which may be either a 
Person or an Organization has something to do with the conduct of an Activity. 
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Object 


3. (Legal) Entity and Unit have been made sub-types of Organization. So have 
Government and Government Agency. 


4. Item Entity Association has become Item Role, the fact that any Party (which 
may be a (Legal) Entity, any other Organization, or even a Person are somehow 
involved with the manufacture or sale of an Item. 


5. The Activity that is an Item Transaction has been renamed Contract—a legal 
arrangement between two (or more?) Parties whereby one provides an Item to 
another, in exchange for remuneration. This allows one of the sub-types of Activity 
Item Transaction to be designated as Contract Line Item. This is a component 
of a Contract that refers to exactly one Note that in UML, you can designate the 
specific relationship between Contract Line Item and Contract as a sub-type of the 
relationship between Activity Item Association and Activity. 


Similarly, the relationship between Activity Conveyance Association and Conveyance 
can be designated as a sub-type of Activity Item Association and Activity. 


Note that no other entity/relationship notation can show that. 


6. Both Document and Image have become sub-types of Information Resource 
Definition. This refers to the content of an Information Resource. This body of 
content may be realized as one or mote Document Instances. Each of the latter 
must then be stored in (or delivered in) one and only one Medium. 


7. Person Document Association has been extended into Party Information Role. 
That is, it may be played by either a Person or an Organization. Note that each 
Party Information Role must be either p/aed for one Information Resource 
Definition (as in, the author), or p/ayed for one Information Resource Instance (as 
in, the recipient). 


8. Activity Document Association has been renamed to Activity Information Resource 
Role, thus covering the involvement of Activities in the creation of all kinds of 
Information Activities. 


9. Also, in lieu of the UML “enumerations” shown in Figure 15, these are full-blown 
entity types (named ...Category in each case) in this drawing. The implementation 
in XML should be the same. 
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Figure 16: The Improved Model 
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AND Now A WORD FROM OUR SPONSOR... . 


Using the expressive power of XML Schema, NIEM has evolved into a very sophisticated 
structure. The Core schema has been designed so that it can be elaborated upon by any 
agency to produce structures that are tailored to that agency, while still being compatible 
with the Core—and therefore with other agencies. This design is both profound in its own 
right and seems to have been very cleverly implemented. 


Even so, however, by failing to address the semantic issues that can only be made visible via 
a graphic model, NIEM’s creators have made implementing NIEM much more complicated 
than necessary. 


The author of this document is David Hay, President of Essential Strategies International. 


For nearly 30 years, he has been creating data models to capture the essence of a wide range of 
industries, as well as of several government agencies, both in the United States and Canada. 
His books on data model patterns’ ”’ are a reflection of his ability to grasp the underlying 
(relatively simple) structures of what otherwise appear to be complex phenomena. 


For example, in 2014, after about two weeks of digesting the code for NIEM 3.0, it only 
took a couple of days to do a first draft of graphic versions of both the NIEM model itself 
and the “corrected” version for four subject areas of the Core. These are at the heart of this 
document. Producing the “Improved Version” of the four areas took another couple of 
days. Because of the time demands from working full time on another project, plus three 
weeks vacation, production of this document has taken a bit longer. The bulk of it was 
produced in six weeks, and the last few weeks have been spent fine tuning it. 


With Mr. Hay’s vast experience creating models of what is essential to an organization, he is 
much better at it (and certainly much faster) than “data” modelers who are actually modeling 
specific design technologies. 


He likes to characterize himself as being good at finding the underlying simplicity behind an 
ostensibly very complex environment. His motto is found in Occam's Razor, named after 
the 14th century logician and friar, William of Occam’. 


Not only can he create models quickly, Mr. Hay can diagnose problems with other models as 
well. “Data model archeology” is one of his specialties. 


If those responsible for NIEM were to retain his firm, Essential Strategies International, Mr. 
Hay could evaluate the whole Core schema. He could then recommend both immediate 
solutions to logical problems and use patterns to simplify the overall structure as well. 


Consider this document to be what those in the entertainment business would call an 
44 + > 
audition’. 


19 Op. cit,. Hay, Data Model Patterns... 
20 Op. cit., Hay, Essential Model Patterns... 


«  “Entia non sunt multiplicanda praeter necessitatem,” "This translates into English as: 
“Entities must not be multiplied beyond necessity." (Found in 


http://www.math.uct.edu/home/baez/physics/General/occam.html.) 
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The company’s web site is http://www.essentialstrategies.com. A library of his articles is at 
http:/ /articles.essentialstrategies.com. Mr. Hay's resume is at 
http://essentialstrategies.com/dhresume 


Mtr. Hay has two presences on LinkedIn: commerce@essentialstrategies.com and 
dch@essentialstrategies.com. The former emphasizes his consulting practice, and the latter 
emphasizes his books. Both of them have numerous endorsements for data modeling, data 
architecture, requirements analysis, and other areas as well. 
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